I think current logic to get normalized hiddenDays value is really over complicated.

I understand that existing mechanism (getViewOption) to get view option in scheduler isn't suitable, because if a view has a default value, then global value wouldn't apply. I think existing mechanism is very awkward and should be refactored.

But in the meantime, I think it is possible to greatly simplify the logic you've added. Here's how:

1. add this code to scheduler_options_base_widget.ts:

getViewOption(optionName: string)
    if (optionName === 'hiddenDays') {
      return normalizeHiddenDaysViewOption(
        this.currentView?.type,
        this.currentView?.[optionName] ?? this.option(optionName)
      );
    }

    // ...
}

2. Remove skipped days default values from DEFAULT_VIEW_OPTIONS

3. Implement normalizeHiddenDaysViewOption:

const normalizeHiddenDaysViewOption = (view: ViewType, hiddenDays?: HiddenDays) => {
   const value = hiddenDays ? hiddenDays : defaultValueByView[view];
   
    // other checks and error logging

    return value;
}

if need to pass hiddenDays to somewhere, e.g. Header, then just pass it in the config, like 'currentDate' is passed:

private headerConfig(): {
   return {
       hiddenDays: this.getViewOption('hiddenDays')
       // ...
   }
}

I am not sure this is a good idea.

It moves hiddenWeekDays normalization to getViewOption(), but that method works only for the current view. Because of that, NormalizedView would no longer be fully normalized, and DEFAULT_VIEW_OPTIONS would no longer be true internal defaults.

Also, the hidden days logic would be spread across different places instead of being resolved once in normalizeView(). So even if the current code is not perfect, this change would make the design less clear, not simpler.

currentDate is just one simple value, so it is easy to normalize in getViewOption().

hiddenWeekDays is more complex. Its final value depends on the view type, per-view value, global value, and default view settings. So it is better to resolve it in normalizeView(), where the view config is built.

minor: now we have two names for the same entity: skippedDays and hiddenDays. I would suggest to only use one name in the codebase

Using skippedDays internally makes sense because skippedDays is a normalized value, while hiddenWeekDays is a public API option and may contain any user-provided input.

Basically what this getter does is:
if currentView is week or workWeek, then return 7 - skippedDays.length
else return 1

Can you simplify this getter to make it more clear?

Done

Is there a way to check if the currentView is week or workWeek without overriding baseDaysInInterval property in m_view_data_generator_week or m_view_data_generator_work_week?

I mean, something like:

const isWeekLikeView = this.viewType === 'week' || this.viewType === 'workWeek';

return isWeekLikeView
  ? 7 - this.skippedDays.length
   : 1;

Thus we wouldn't need baseDaysInInterval prop at all, because in all other viewDataGenerators apart from week don't override the value of baseDaysInInterval

this func can be private

Done

add protected

The function is being used here /DevExtreme/packages/devextreme/js/__internal/scheduler/workspaces/m_timeline.ts (421,68):
Property 'daysInInterval' is protected and only accessible within class 'ViewDataGenerator' and its subclasses.

and in tests.

Cant make it protected or private

Use the same name for the method:

public isDateSkipped(date: Date): boolean {
    return isDateSkipped(date, this.skippedDays);
  }

Done

resolveSkippedDays calls normalizeHiddenWeekDays(globalHiddenWeekDays) for every view. When hiddenWeekDays contains all 7 days, this will log W1029 once per view, potentially spamming logs. Consider normalizing the global value once (and logging once) before mapping views, then reusing the normalized result for each view.